**在講完最前端透過 DNS 做的 GSLB, 以及最後端資料庫 DB 做的 Replication 後, 我們來看一下中間層的 Server Load Balance 以及 Network Load Balance 吧.

在實作與應用 SLB 與 NLB, 大部份都是用幾種方式:

1. 請 IDC 直接做 SLB 服務, 他們可能也是用設備或自己實作.
2. SLB 的設備, 或直接用 AFE (Advanced Front End) 做完一切.
3. 自己架設 SLB 的系統, 透過一些付費程式或開放源碼的程式.
4. 在應用程式做 Dispatcher 做分流.**
   在大部份的時候, 我會通常對於一些經驗還沒那麼足夠的管理者, 可以買設備來做, 但重點是還是要自己實作才行, 因為我知道很多人不只是買設備, 還直接請 SI 場商做掉了, 但若因此對於實務沒有一定的經驗, 若出事情要做 Trouble Shooting 的話, 時效會有很大的延遲, 所以最好還是有自己的能力.

當然在實務上的運作, SLB 不是透過 Virtual IP 的概念, 就是透過 Redundent IP 的觀念來實作, 但實務上我比較少看到有人用 Redundent IP 來作, 若有的話請跟我說, 大部份還是透過 VIP (Virtual IP) 與 Real IP (RIP) 來做 Directing or Mapping or Routing or Forwarding 的方式來實作.

上兩篇用 DNS 來實作一些 SLB 或 GSLB, 會發生一個問題, 就是 DNS 本身一定會有 Cache 機制, 有時候只靠 SOA 或 TTL 是無法解決的, 若 GSLB 一定要靠 DNS 來作就算了, 而 SLB 是未必一定要這樣做, 尤其若是靠 DNS 來實作 SLB, 不只是延遲的問題, 真的要去做問題解決 Trouble Shooting 不只是要靠時間, 事實上還真的有時是做不到的, 所以倒不是 Heart Beat 或者是分流方法的不同.

說到分流, 這是每一個做 SLB 管理者一定要知道的, 下面就是幾種目前 IPVS 可以實作的分流排程方式:

* Round-Robin Scheduling
* Weighted Round-Robin Scheduling
* Least-Connection Scheduling
* Weighted Least-Connection Scheduling
* Locality-Based Least-Connection Scheduling
* Locality-Based Least-Connection with Replication Scheduling
* Destination Hashing Scheduling
* Source Hashing Scheduling
* Shortest Expected Delay Scheduling
* Never Queue Scheduling

為甚麼 Scheduling 排程是很重要的呢? 因為要去做分流, 管理者要知道採取甚麼樣的分流機制是最好的, 像 DNS 能做的大概就是很基本的 Round-Robin 以及偷機取巧的 Weight RR 方式, 但相對的若是用自己程式來實作的話, 甚至可以用 Estaimate Finished Efficency 的計算方式之類的, 也就是說, 越自己實作, 越能夠量身訂作最好的, 但也要付出一定的代價.

上面的 Scheduling 有幾個重點:

1. Round Robin 與否
2. Weight 與否
3. 最少的甚麼東西

當然 Scheduling 排程最後還是要自己去想, 在這邊我還是要講一個基本觀念就是 One Arm 還是 Two Arms 的 SLB:

1. One Arm: 就是 SLB 只有一條網路 (邏輯上的) 接到 Uplink 的 Switch 及 Server.
2. Two Arms: SLB 的 Uplink 與到 Server 是走不同路.
3. Hybrid: 邏輯上有時是走同一條路或不同條路, 如 Server Direct Return.

這差異性在於 Security 以及 Topology 的差異, 甚至是在網路架構做決定.

這一系列文章我通常是要求原創, 但看到 Monster Oasis 作了一張表真的是太好了, 連我很少放圖的文章我都願意拿來放.

雖然上面的比較表講了不少, 但很多還是要靠幾個系統的一起實作, 才能夠做到更高的有效性, SLB 也只是一個環節而已, 能夠實作的還是很多, 無論你是買服務, 買機器, 用軟體還是自己寫, 因為 HA 的環節真的太多了.